One common memory management technique, called virtual memory, abstracts physical address space of a memory system into a virtual address space for use by applications executed by a processing system. For example, the processing system can generate the virtual memory addresses, map them to physical memory addresses in the memory system, and assign different, non-overlapping sets of the virtual memory addresses to different applications running on the processing system. The processing system, typically through a combination of hardware exceptions, hardware address translation, main memory, disk files, kernel software, or the like, can manage allocation and release of the virtual address space for the applications running on the processing system.
While the abstraction of physical memory into virtual memory can free applications from having to manage shared physical memory among themselves and allow the processing system to avoid overlap in physical address utilization by different applications running on the processing system, many applications as-written can utilize virtual memory improperly—causing memory corruption. Some of the common types of memory corruption include buffer overrun and utilization of invalid or destroyed objects. Buffer overrun can occur when a function in an application is allocated a block of virtual memory addresses by the computing system, commonly including one or more memory pages, and the application reads or writes to virtual memory addresses outside of the allocated block of virtual memory addresses. The utilization of invalid or destroyed objects can occur when a function in an application releases or frees a virtual memory address from allocation to the function, but the function attempts a memory access to the freed virtual memory address anyway, possibly reading or writing data corresponding to a different function in the application. The utilization of invalid or destroyed objects also can occur when a function in an application releases or frees a virtual memory address from allocation to the function even though the virtual memory address was already free from allocation, sometimes called a “double-free” memory corruption.
Since these types of memory corruption occur due to defects in the programming of the application, some application developers utilize memory verification tools, sometimes called memory debuggers, to analyze the operation of the applications in the processing system to determine whether they are written in a way that can cause memory corruption. While these memory debuggers can identify whether an application incurs some of the common types of memory corruption, they often consume a large amount of memory resources to do so. For example, in order to identify whether a function in the application attempt to access or free and already freed virtual memory address, the some memory debuggers will never actually release the allocation of the virtual memory address, but rather keep them as placeholders to detect possible actions indicative of memory corruption. By never releasing or freeing virtual memory addresses, the memory debuggers rapidly consume physical memory mapped to the virtual memory space, which, in absence of a memory corruption event, remains unused by the application. For smaller applications, memory systems may have a large enough physical memory to accommodate this particular verification scheme, but the memory debuggers can run out of physical memory when attempting to verify operation of larger applications.